In case of errors, the `InferenceClient.do_bulk_inference` method
will now return `None` for the affected objects instead of aborting
the entire bulk inference operation (and discarding any successfully
processed objects).

Fixes issue #68

The fix for #68 is different than what is described in #68. Instead of
using a generator based approach which will require the SDK consumer to
implement the error handling themselves, the SDK itself now handles the
errors. The downside of not using a generator is a larger memory footprint
to accumulate the results in a list. As an alternative, we can consider
using a generator to either yield the successfully processed inference
results or the list containing `None`. This approach will save memory.

Additionally, this commit introduces parallel processing in `InferenceClient.do_bulk_inference`.
This will greatly improve performance. Due to the non-lazy implementation of
`ThreadPoolProcessor.map`, this increases memory usage slightly ([cpython issue #74028])

[cpython issue #74028]: python/cpython#74028

…ence

This also contains a documentation formatting fix.

This reverts commit 4372b8f.

setuptools must be installed much earlier in the process.

The bulk_inference code is now multithreaded. For this reason, the trick of
returning different values in the Mock based on the order of the calls no longer works.
This was somewhat accidentally working on CPython, but not on pypy.

This is mainly useful to fix the tests which rely on the
mocks being called in a certain order. One of the tests supports
concurrency by mocking in a better way, but this was not feasible
for the other tests.

This commit also updates the documentation build tools to the
latest version to fix the documentation build on my local machine.